Outbound operations
When performing Client Outbound operations (from BizTalk), we have the ability to select the following contract types:
If we expand the BAPI node, we will discover that our schemas are sorted based upon their functional role in the SAP system.
Inbound Operations
When performing Service Inbound Operations (to BizTalk), we have the ability to select the following contract types:
Calling RFCs/tRFCs hosted in BizTalk
If you recall, one of the key differences between
RFCs and BAPIs is the Business Object Repository. BizTalk does not store
these Business Objects anywhere so it is not possible for BizTalk to
host a BAPI as the underlying function module will not be available.
What is interesting about BizTalk hosting an RFC is
that SAP could consume it and would not even know that it is calling an
external system as opposed to another SAP system. Obviously, the BASIS
administrator that is configuring the endpoint would, but Microsoft is
leveraging SAP's RFC SDK to ensure interoperability. This architecture
also presents some interesting opportunities if your organization was
against customizing SAP. You could abstract this functionality away from
SAP and have it implemented in a more agile environment like BizTalk.
Perhaps your organization does not have the ABAP skillset, or resource
bandwidth, to code an RFC and chooses to leverage a BizTalk skillset
instead.
A more practical, and likely, use of RFCs being
hosted in BizTalk is data residing outside of SAP and SAP needs to
obtain this information in a synchronous fashion. In this case, SAP
would call a BizTalk hosted RFC, and BizTalk would retrieve the
downstream information and return it back to SAP.
A real world example of BizTalk hosting an RFC is an
Energy company that needed to retrieve Meter Reads from an External
system via Web Services. This company did not have the SAP experience or
technology stack to support calling external Web Services securely from
SAP. These external Web Services used complex types, were secure, and
were hosted in the partner's data center. The solution to this problem
included BizTalk hosting an RFC that SAP could call on demand. In turn
BizTalk would fetch the required Meter Read information from this
external system and return the results back to SAP in a format that SAP
was expecting.
Custom objects
If we are looking for custom objects (for example
RFC), we will find them in the \RFC\OTHER hierarchy. SAP best practices
indicate that whenever you have a custom object, you prefix it with the
letter 'Z'. This is a great concept, especially for non-SAP resources
whose first language is not German. While the documentation and naming
conventions are improving, there are still a lot of tables, fields, and
programs that use German words or acronyms that make absolutely no sense
to an English speaking BizTalk person. By leveraging this practice of
prefixing custom objects with "Z", both SAP and Microsoft resources can
easily identify custom objects.
Transactions
When calling BAPIs that perform Create, Update, or
Delete operations, it is necessary to generate schemas for two
additional operations:
Calling either of these operations is required since
we may be manipulating multiple sets of data and we either want all of
the data to be successful or none of it to be successful.
For convenience purposes, we will generate all of these schemas at the same time. It is important to note that the BAPI_TRANSCTION_COMMIT&; and BAPI_TRANSACTION_ROLLBACK
operations are generic and can be used in conjunction with other BAPIs.
If you plan on having multiple BAPI integration scenarios within your
environment, placing these schemas in a common project may be a more
sustainable solution.
